1. Field of the Invention
The present invention pertains to speeding up the Java processor in executing bytecodes, and more particularly to a method and a system for stack-caching method frames on a Java platform.
2. Description of Related Art
In conventional programming language, the source code is compiled into specific machine code by a processor. The machine code is thus executed in a specific processor. If it is desired to execute the program in a different processor, the source code must be re-complied into the machine code of that processor.
Java is an object-oriented programming language and has the features of cross-platform and concise bytecodes. To achieve the capability of cross-platform in Java, the source code is converted into bytecodes in compiling, wherein the bytecodes are virtual machine (VM) instructions for executing the Java program, instead of being the instructions of a specific processor. In executing a Java program, the bytecodes are sequentially translated into instructions for a specific processor by a bytecode interpreter, which is a component of the Java virtual machine. Accordingly, after being compiled into bytecodes, the Java program can be executed in any platform and operating system with Java virtual machine platform.
Such a Java program suffers a disadvantage in that the execution speed is low. As known, the conventional machine codes obtained from compiling a program can be directly executed in a processor. However, the bytecodes obtained from compiling the Java program must be interpreted into machine codes by a Java virtual machine for being executed one a processor, resulting in requiring one additional process.
One solution to overcome the aforementioned problem is to use a Java processor capable of directly executing the bytecodes without the interpretation of the byecode. The Java processor is a stack-based processor, wherein, in any time, the stack-based processor only executes a single method, i.e., the current method.
FIG. 1 is a schematic diagram of the use a stack cache 1 showing the address space of method. The stack cache 1 is temporarily stored with at least one method frame 11, which defines an address space corresponding to the method. Each method frame 11 includes a plurality of frame components, such as object reference 111, arguments 112, local variables 113, frame state 114 and operand stack 115 for performing operations, invoking method, and accessing local variables. The frame state may include the return program counter, return frame, return constant pool, current method vector and current monitor address.
In the operation of a Java processor, the stack cache 1 is operated as follows. At first, data is read from the local variables 113 and pushed into the operand stack 115. Operand is popped from the operand stack 115 for some computation, and the result is pushed into the operand stack 115. Logically, it can be considered that the local variables 113 are at the bottom of the stack cache 1. The frame state 114 is above local variables and the operand stack 115 is at the top.
In the process of executing the bytecodes by the Java processor, the operand stack 115 may grow continuously to be out of the stack cache 1. Therefore, an auto spill and fill mechanism is employed. When the operand stack 115 grows and the usable space of the stack cache is reduced to a predetermined level, the auto spill mechanism is enabled so that data at the bottom of the stack cache 1 is moved to the memory (not shown) (hereinafter, the space of the memory for storing the stack is named as memory stack) for increasing the usable space of the stack cache 1. Therefore, in operating the Java processor, the local variables 113 may be stored in the stack cache 1 or in the memory stack.
FIG. 2 schematically illustrates the operation of a conventional Java processor. When desiring to access the local variables 113 (step 201), it is necessary to determine whether the local variable 113 to be accessed is stored in the stack cache 1 or in the memory stack, wherein VARS is pointer for the local variables, and BOS points to the bottom of the stack cache. A link register points to the memory stack corresponding to the bottom of the stack cache 1. When performing the auto spill and fill, the link register serves as base for spilling from and filling in the memory. For example, when the “iload” instruction is executed and the N-th local variable must be accessed, the Java processor must determine whether the VARS+N is smaller than BOS. If yes, it represents that the local variables are currently stored in the memory stack, and the value of the local variable is stored at the memory address (VARS+N)*4 (step S202). If not, it represents that the local variable is stored in the stack cache 1, and the value of the local variable is stored in the stack cache entry pointed by VARS+N (step S203).
In the execution stage of the Java processor, when desiring to access the local variables, it is necessary to determine whether the local variable 113 is stored in the stack cache or in the memory stack for processing different processes, respectively, which may result in a complicated and error-prone hardware for a pipelined processor. Besides, if the local variables are stored in the memory stack, the required memory access operation including addition and multiplication operations will spend a lot of time, resulting in a low executing performance.